Fix DDL failure for hasMany collections of enums - #16052

Pull request overview

This PR fixes Hibernate schema-generation (DDL) failures for hasMany collections of enums in grails-data-hibernate7 by ensuring enum collection elements bind their column to the join table (not the owning entity table) and by stabilizing the derived element column name (simple enum name vs fully-qualified name). It also refactors enum binding so both singular-enum properties and enum-collection elements flow through a single EnumTypeBinder.bindEnumType(...) path, with each HibernateEnumProperty implementation providing its enum/table/column/nullability details.

Changes:

• Fix basic collection element table resolution so enum element columns are added to the collection join table rather than the owning entity table.
• Correct join-table element column naming for enum collections to use the enum simple name instead of the fully-qualified name.
• Consolidate enum binding into a single binder entry point and add/adjust tests to cover the DDL and binding behavior.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

I had AI review this and think it's comments are relevant. Take a look and then I'll take another pass.

Approving — the fix is correct and now properly guarded. Reverting joinTableColumName to getName() fails three EnumHasManyDdlSpec features, so the regression is genuinely pinned. The round-one items all landed and I've resolved those threads: EnumHasManyDdlSpec asserts exact column names and reads inside doReturningWork with try-with-resources, the joinTable column: and nullable: false cases are there, the GrailsPropertyBinder guard moved onto the interface as isCollectionElement(), and the HibernateEnumProperty javadoc is accurate. The extra HibernateCustomProperty coverage in GrailsPropertyBinderSpec is a good addition too.

Everything below is non-blocking follow-up — none of it is a correctness problem and none of it should hold up the fix. Findings are verified by mutation: I broke the production code and checked whether the suite noticed, rather than inferring from reading.

Three tests that don't assert what they're named for

1. EnumHasManyDdlSpec, the ordinal feature. Substituting enumType: 'string' for 'ordinal' leaves it green. Column names are identical under both styles, and the round trip reads through the mapping it wrote.
2. HibernateMappingFactorySpec. Deleting the HibernateBasicEnumProperty branch outright leaves it 29/29 green — all three createBasicCollection features assert the supertype.
3. HibernateToManyPropertySpec (carried over from round one, still unchanged — I've left that thread open). Its joinTableColumName feature asserts != null and passes against the bug it is named for.

None of these are uncovered behaviour — the suite catches all three regressions elsewhere, which is why they stayed green. They're tests that wouldn't fail if the thing they're named for broke, and each is a small fix. Happy for them to land as a follow-up rather than here.

One design question

HibernateBasicProperty.getTable() is overridden on the shared base class, but only the enum path reads it, and it changes what TableForManyCalculator.getJoinTableSchema() sees. That still yields the right schema, but only because CollectionType.create() seeds collectionTable to the owner's table before getJoinTableSchema() runs. Details inline — worth deciding deliberately rather than inheriting, but not a blocker.

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated no new comments.

        if (!pc.getColumns().isEmpty()) {
            ColumnConfig columnConfig = pc.getColumns().get(0);
            indexBinder.bindIndex(columnName, column, columnConfig, t);
            columnConfigToColumnBinder.bindColumnConfigToColumn(column, columnConfig, pc);
        }